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Abstract — Distributed Spacecraft missions are an integral 
part of current and future plans for NASA and other space 
agencies. Many of these multi- vehicle missions involve 
utilizing the array of spacecraft as a single, dispersed 
instrument requiring co mmuni cation via crossl inks to 
achieve mission goals. NASA’s Goddard Space Flight 
Center (GSFC) is developing the Formation Flying Test Bed 
(FFTB) to provide a hardware-in-the-loop simulation 
environment to support mission concept development and 
system trades with a primary focus on Guidance, 
Navigation, and Control (GN&C) challenges associated 
with spacecraft formation flying. The goal of the FFTB is 
to reduce mission risk by assisting in mission planning and 
analysis, providing a technology development platform that 
allows algorithms to be developed for mission functions 
such as precision formation navigation and control and time 
synchronization. The FFTB will provide a medium in 
which the various crosslink transponders being used in 
multi-vehicle missions can be integrated for development 
and test; an integral part of the FFTB is the Crosslink 
Channel Simulator (CCS). The CCS is placed into the 
communications channel between the crosslinks under test, 
and is used to simulate on-mission effects to the 
communications channel such as vehicle maneuvers, 
relative vehicle motion, or antenna misalignment. The CCS 
is based on the Starlight™ software programmable platform 
developed at General Dynamics Decision Systems and 
provides the CCS with the ability to be modified on the fly 
to adapt to new crosslink formats or mission parameters. 

This paper briefly describes the Formation Flying Test Bed 
and its potential uses. It then provides detail on the cunent 
and future development of the Crosslink Channel Simulator 
and its capabilities. 
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Acronym List 
CCS: Crosslink Channel Simulator 

DSP: Digital Signal Processing 

DSS: Distributed Space Systems 

ENV: Environment computer 

FFTB: Formation Flying Testbed 
GN&C: Guidance, Navigation, and Control 
GPS: Global Positioning System 

GPSSG: GPS Signal Generator 
GSFC: Goddard Space Flight Center 
NASA: National Aeronautics and Space Administration 
PN: Pseudorandom Noise 

RF: Radio Frequency 

UDP : Universal Datagram Protocol 


1. Introduction 

In the past, NASA’s space-based missions have been 
organized around a single, typically large spacecraft 
carrying out all of the mission functions. As mission 
requirements grow to include science output that a single 
spacecraft alone cannot provide, this paradigm is changing 
to incorporate missions that utilize multiple spacecraft 
working as a single observing system. For example, some 
Distributed Space Systems (DSS) missions will rely on 
arrays of distributed spacecraft to form a single distributed 
aperture, using long baselines and interferometry to observe 
distant objects and events in great detail. A single 
spacecraft can only achieve the spatial diversity on the scale 
of its own structure, whereas the spacecraft array can form 
an effective aperture bounded only by the (engineering) 
limits on intersatellite separations. Other missions will 
utilize distributed in-situ measurements in order to 
distinguish spatial and temporal variations in the space 
environment. For example, the Magnetosphere MultiScale 
(MMS) mission [1] will utilize a constellation of four 
spacecraft to make measurements of the three-dimensional 
structure and dynamics of the key boundary regions of the 
Earth’s magnetosphere. 
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DSS missions also have the potential to reduce mission 
costs. Commercial spacecraft production will be able to 
reuse designs, components, and manufacturing that will 
make for smaller, less expensive and more reliable 
spacecraft. Also, if one unit fails the mission can still 
proceed with reduced capacity, a concept often referred to 
as graceful degradation. 

Some of the future missions including constellations or 
formations of spacecraft planned by NASA are: 

• Magnetosphere MultiScale (MMS) [1] 

• Geospace Electrodynamic Connections (GEC) [2] 

• Magnetospheric Constellation (MagCon) [3] 

• Constellation-X [4] 

• Terrestrial Planet Finder (TPF) [5] 

• Laser Interferometer Space Antenna (LISA) [6] 

• Stellar Imager (SI) [7] 

• MAXIM & MAXIM Pathfinder [8] 

To achieve the science goals for these missions, each 
spacecraft in the constellation may carry a set of 
instrumentation which collects data that must be sent back 
to the mission operators on Earth. In some cases, only one 
of the spacecraft has a high-gain antenna that is used to 
transmit the mission data back to Earth, and the data from 
the other space vehicles in the constellation must be passed 
over so it can be transmitted as well. 

Furthermore, some of these missions require the spacecraft 
to fly in formation, that is, to control their relative position 
and/or attitude. Formation flying generally requires the 
estimation of relative position, velocity, and attitude, which 


is also called relative navigation. In such a system requiring 
relative navigation and control, the intersatellite 
communications device (crosslink) can serve a dual role: 1) 
to provide a means of intersatellite communications, which 
is required to a share measurements and control messages 
such as maneuver co mma nds and 2) to make direct 
measurement of the scalar distance between spacecraft, also 
called ranging. Through these roles, the crosslink becomes 
a critical technology for successfully closing the control 
loop for formation flying systems. Figure 1 shows an 
artist’s rendition of a satellite formation utilizing cross link 
capabilities. 

Consequently, it is important that the FFTB acquire the 
capability to insert crosslink hardware into its simulation. 
Of course, crosslinks can be connected directly to one 
another in the FFTB using coaxial cables and attenuators, 
and this configuration is useful to establish a 
communication path through the crosslink hardware and to 
test the interface between the crosslinks and the flight 
software. However, direct connection of the crosslinks does 
not account for effects on the signal, such as delay, Doppler 
frequency shift, and attenuation, which are functions of the 
satellites’ states (position, velocity, attitude) and geometry. 
The Crosslink Channel Simulator (CCS) is inserted into the 
communication paths between the crosslinks to introduce 
these effects. Introduction of crosslink hardware and state- 
based signal effects to the FFTB will provide a realistic 
representation of intersatellite communications and ranging, 
enabling integration and test of formation flying navigation 
and control algorithms in a high fidelity, hardware-in-the- 
loop simulation environment. 
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This paper discusses the development of the FFTB, its uses enabling technology. The FFTB seeks to provide this 

and capabilities, as well as the details of the CCS including simulation capability; its role includes investigation of DSS 

future upgrades for the system. mission feasibility, definition of engineering requirements, 



Figure 2: Block Diagram of the FFTB Configuration 


2. The Formation Flying Testbed 

Many of these DSS missions require control of the 
satellites’ relative position and/or attitude; these missions 
will be referred to as formation flying missions. Among the 
formation flying missions, there exists another subset whose 
relative control requirements are so demanding that they 
will require nearly continuous control; these are termed 
precision formation flying missions. NASA has an 
abundance of DSS missions on its roadmap, and several 
examples have already been mentioned in the previous 
section. Among these, MMS is an example of a formation 
flying mission, and Stellar Imager and Maxim are both 
precision formation flyers. 

The fact that formation flying systems are significantly 
different and potentially more complicated than the 
traditional single satellite systems provides motivation to 
build hardware-in-the-loop simulation capabilities such that 
these systems can be conceived and developed within a 
realistic ffamew'ork and with an eye towmrd identifying 


maturation of required sensor and actuator hardware and 
GN&C software, and validation of GN&C system 
performance. 

A core tenet in the design of the FFTB has been the 
development of the capability to include GN&C hardware in 
the simulation loop. GPS receivers were the first to be 
included in FFTB simulations due to the availability of GPS 
signal generators as well as receiver hardware. While 
simulations of GPS-based DSS missions have been useful, it 
has become clear that the hardw'are-in-the-loop simulation 
of formation flying systems must grow to encompass the 
satellite crosslinks. Crosslinks provide two major functions 
from an engineering perspective, namely intersatellite 
communication and intersatellite range measurement. 
Intersatellite communications enable the distribution of 
satellite commands and the sharing of engineering data. 
Intersatellite ranging is a key measurement for input to the 
relative navigation system. 

The CCS, detailed in the next section, is the mechanism by 
which the FFTB is incorporating crosslink. It is envisioned 
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that the CCS will enhance the FFTB’s current closed loop 
formation control simulation by enabling the loop to be 
closed through real crosslink hardware. 

A schematic diagram of the FFTB is shown in Fig 2. The 
Environment computer is responsible for the numerical 
integration of the satellites’ equations of motion thereby 
generating truth trajectories including time, position, 
velocity, attitude, and attitude rates (t, x, dx/dt, q, dq/dt). 
This trajectory information is then delivered in real time to 
the GPS Signal Generator (GPSSG) and the CCS. Armed 
with the knowledge of the receivers’ states, the GPSSG 
generates a Radio Frequency (RF) signal that simulates the 
received signal from the GPS constellation complete with 
time delay and Doppler shifting. Similarly, the CCS 
provides RF signal to the cross links which represents the 
signal which would be received by the crosslinks during 
their space mission including time delay, Doppler frequency 
shifts, and attenuation based on the current relative states of 
the transmitting and receiving satellites. The on-board 
processor hosts the flight software including the navigation 
and control systems. GPS measurements are delivered to 
the on board processor for inclusion in the navigation 
processing. Depending on the navigation and control 
schemes, the processor may then send out data or 
commands to the other satellites through the crosslinks. 
Maneuver commands (u) are also fed back to the 
Environment computer for integration into the equations of 
motion. Consequently, the crosslink hardware is in the 
critical path for closing the formation control loop and 
underscores the motivation for including it in the FFTB 
simulation. 

3. Crosslink Channel Simulator (CCS) 

The development of the CCS is progressing in two phases. 
In the first phase, General Dynamics Decision Systems has 
designed and built a prototype CCS for the FFTB. The 
prototype CCS, built in fiscal year 2003, supports an RF 
crosslink frequency of 2448MHz and provides partial RF 
functionality. That is, it operates in a “talk-only” mode in 
which it is capable of generating the RF signal for the 
receiver without “listening” to the signal from the 
transmitter. This is accomplished by adding data content to 
the messages the CCS receives over Internet Protocol (IP) 
socket connection from the ENV. While the prototype CCS 
enables the introduction of hardware-in-the-loop 
communications and ranging to the FFTB, its “talk-only” 
limitations mean that the transmit functionality of the 
crosslink hardware is not utilized in the simulation. 

The second stage of CCS development, occurring in fiscal 
year 2004, will enable 1) full RF functionality i.e., the 
ability to receive RF signal from the source crosslink and 
transmit modified RF signal to the destination crosslink, 2) 
the capability to support a network of four crosslinks, and 3) 
communication over a wider range of frequency bands, 
ideally making it compatible with all existing crosslink 
transponders. 


The space-to-space signals transmitted between crosslinks 
will experience several communications channel effects 
which are duplicated in simulation by the CCS. These are: 
Doppler shift caused by the relative motion of the 
spacecraft; signal attenuation caused by free space loss 
between the two spacecraft or other losses such as antenna 
mispointing; and signal delay caused simply by the time of 
signal transit between the two spacecraft. The CCS 
simulates all three of these channel effects very precisely, 
with signal delay simulated down to 1cm of range accuracy, 
or about 33 picoseconds for a typical S-band crosslink. 
Doppler shift is simulated down to less than lmm/s, and 
signal attenuation is controlled to O.ldB. The 1cm accuracy 
requirement over the entire possible range of spacecraft 
separation distances (from 0 to 6400km or more) drove the 
design to perform baseband signal processing to implement 
the c hann el effects instead of direct RF/IF sampling. 
Delaying the crosslink signal by 33 pS (corresponding to 
lcm of range difference) corresponds to approximately a 30 
GHz sampling rate which is not available with current 
technology. Therefore, advanced signal processing 
techniques were used to simulate the crosslink signal ranges 
down to the lcm resolution. 

In the second phase of development, the CCS must have 
two-way communications with both spacecraft 
transponders; it must be able to receive and transmit the 
crosslink signal structure, in effect being able to act as a 
two-way crosslink transponder itself. After one crosslink 
transmits its RF signal to the CCS, the CCS must 
demodulate the signal, stripping it of its carrier and PN 
code, induce the appropriate channel effects, remodulate the 
signal onto the appropriately modified RF carrier, and 
transmit the modified signal to the receiving cross link 
transponder. 

One of the major requirements of the CCS was that it be 
able to communicate with a wide variety of crosslink 
transponder devices using their own transmit and receiver 
frequencies, message formats, and data rates. This 
requirement drove the CCS design to include a 
reconfigurable hardware system that can be changed via 
software to transmit and receive a new signal format. This 
requirement was met by using the General Dynamics 
software programmable communications processing 
platform known as the StarLight™[9]. The StarLight 
architecture implements an optimized combination of RF 
signal processing, ASIC-based digital signal processing, and 
software signal processing and control. The StarLight 
supports varied application types (from GPS to high-speed 
crosslinks), signaling formats, and is reconfigurable “on the 
fly.” 

System Overview 

Figure 3 shows the system block diagram of the protoype 
CCS. The major components that comprise the CCS 
hardware are two RF boards, a digital board, several 
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Figure 3: Crosslink Channel Simulator System Block Diagram 



digitally-programmable attenuators and a power supply. 
The digital and RF cards are based on General Dynamics 
software programmable communications processing 
platform known as the Starlight. These cards and the other 
supporting hardware are installed into a 19” Rackmount 
chassis for installation into the FFTB at GSFC. Figure 4 
show's a picture of the prototype CCS box in the rackmount 
chassis. The CCS accepts an external reference 1 0MHz 
clock and a 1 Pulse Per Second ( 1 PPS) input to synchronize 
it with the rest of the FFTB equipment. 

Each of the two CCS RF cards provides one RF receiver 
input and one RF transmitter output via N-type connectors 
on the front cover of the CCS rackmount chassis. The S- 
band RF downconverter chain contained on each board 
provides a downconverted second IF frequency output to the 
CCS digital card. To facilitate the transmit function, the RF 
cards accept baseband in-phase (I) and quadrature (Q) 
signals from the CCS digital card modulate these signals 
onto RF carriers. The frequency synthesis for the receiver’s 
local oscillator signals, the transmitter carrier frequency and 
the clock signal for the StarLight card are all provided by 
the RF assembly and are phase locked to the externally 
supplied 10 MHz reference oscillator input. A 102.4 MHz 
clock is generated on both RF cards, and this clock signal is 
routed from one of the RF boards to the digital card to be 
used as the system clock. 


The CCS digital card provides all of the command and data 
handling, any necessary parameter calculations, transmitter 
and receiver control, and other signal processing functions. 
Commands to the CCS through its Ethernet port are 
interpreted and processed by the onboard ColdFire® 
processor. These commands can contain CCS configuration 
commands or requests and simulation parameters such as 
time delay, attenuation, and Doppler shift. 

The digital card provides analog to digital converter (ADC) 
inputs connected to the IF outputs from each of the two 
receiver channels on the CCS RF cards. Each ADC samples 
one of the IF signals at the system clock rate and inputs the 
samples to the Digital Signal Processing (DSP) gateware 
where appropriate techniques are applied to extract and 
process the signal modulated onto the received carrier. 

The transmitter portion of the CCS digital card accepts a 
single data stream provided by the processor after it has 
been extracted from the received messages. Depending 
upon the current configuration of the CCS, this data stream 
could be re-formatted (e.g. from NRZ-L to NRZ-M), 
encoded, interleaved, or combined with a Pseudorandom 
Noise (PN) code. The CCS then buffers the data, modulates 
it onto a baseband carrier at the required Doppler offset, and 
then sends it to the RF transmitters at a specific time so the 
data appears to be delayed and channel-modified to the 
receiving crosslink. 
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Software Architecture 

The software developed for the CCS provides an interface to 
configure, monitor, and manage channel data during 
simulations run on the FFTB. Using VxWorks® 5.5 kernel 
from Wind River Systems, Inc. for the Coldfire CPU, the 
CCS software is designed to react to the needs of the 
configured hardware to provide it both the message buffer 
data stream as well as computed signal manipulations 
provided by the ENV. 

The ENV provides the channel parameters with each 
message to be transmitted. These parameters include 
acceleration, Doppler, signal delay, and attenuation. The 
channel-processing task takes these parameters and 
generates data packages that will be used by the associated 
interrupt service routine to provide control signals to the 
transmitter hardware. The acceleration and Doppler 
parameters are used in conjunction to provide updates to the 
transmitter frequency at a specified interval. The ENV is 
responsible for maintaining the continuity of all parameters 
between each message packet. 


Hardware/Software integration cycle was short due to: 1) 
Stable hardware definitions and memory map; 2) VxWorks 
Tornado fast cycle time for Test, Debug, Correct; and 3) 
Significant testing with the VxWorks Simulator. An HP 
VEE application was also developed to simulate the ENV 
and validate the UDP communication formats. 

4. Future (Planned) Capabilities 

Figure 5 shows the basic block diagram for configuration of 
the CCS after phase two of the development. As mentioned 
previously, this configuration upgrades the current CCS to 
include the ability to place up to four crosslink transponders 
simultaneously into the FFTB. The future CCS will include 
the following: 

• Full RF functionality 

• Four transmitters 

• Four receivers 

• Routing between the four communication paths 

• Greater frequency agility 


The pilot development of the CCS software occurred over a 
6-week period. Software was developed using C on 
VxWorks Tornado for Windows 2000 workstations. The 
VxWorks Simulator, provided with this platform, provided 
an environment to develop software as the hardware was 
completed. This allowed the engineers to develop and test 
all tasking, inter-process communication, and message 
processing behaviors prior to integration on the StarLight 
Platform. CCS was able to leverage the UDP utilities 
developed during a previous StarLight-based project [9]. 


With this set of upgrades, the FFTB will move beyond the 
simple point-to-point communications and ranging 
interaction of a two-satellite formation. Support for four 
crosslinks will enable more complex and realistic 
communications and ranging schemes. Full RF 
functionality of the CCS will allow for the exercise of the 
crosslink’s transmit function, building more confidence in 
the realism of the simulation. 
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5. Summary 

The GSFC Formation Flying Testbed will provide a facility 
to simulate the crosslink communications and relative 
navigation between spacecraft on the ground, prior to 
launch. Since many future NASA programs include 
formations of spacecraft relying on intersatellite 
communications, the FFTB will become an increasingly 
important tool in the success of these missions. 



Figure 5: Future Configuration of the CCS 


The Crosslink Channel Simulator developed by General 
Dynamics is one of the major enablers of the FFTB. It 
provides the FFTB with the ability to simulate the physical 
effects of the mission environments, including Doppler 
shift, signal attenuation, and delay. Because the CCS was 
developed using the Starlight ™ reconfigurable hardware 
platform, it can easily be commanded via software to 
interface with a wide variety of crosslink transponder 
hardware. This allows NASA to evaluate many crosslink 
options for each mission with one set of FFTB equipment. 

The initial development of the CCS has been demonstrated 
in the FFTB facility at GSFC. In 2004, development of the 
CCS will continue towards its future configuration to enable 
up to four crosslink transponders to simultaneously operate 
in the FFTB. 

Starlight ™ is a trademark of General Dynamics, ColdFire® 
is a registered trademark of Motorola, Inc., and VxWorks® 
is a trademark of Wind River Systems, Inc. 
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